1. Field of the Invention
The present invention is directed to security in the field of data processing, and in particular to a method, system and computer program for easily and securely managing multiple keys used to have access to one or a plurality of computing resources.
2. Background Art
To reach sensible pieces of information, users must first be authorized to have access to the applications, web pages, or databases containing this sensible information. In fact, sensible information can be in any kind of information repository, application or computing resource. Such information repositories or computing resources, regardless of their nature and implementation, will be referred to herein as “DataSets”. The access to a DataSet is usually protected to avoid unauthorized users to retrieve information that they are not allowed to reach. The protection of information and the control of its access are typically achieved by means of user identifiers (UserId) and passwords. In some cases, the protection and control means are not limited to UserId and password, and may also comprise other fields like an account identifier (AccountId), or a server identifier (ServerId), etc . . . All these pieces of information required to get access to a given DataSet will be referred to herein as the “Key”, regardless of the number of individual fields (such as UserId, or password, or AccountId, etc . . . ).
The number of Keys that typical users must own (either for business or personal needs) is such that the observance by these users of the password management policies (like the rules password must comply with, or the frequency for updating password) lacks efficiency, safety and friendliness. Indeed all users have to record one way or the other, multiple Keys. The record of these Keys rends them either unsecured or difficult to locate. Typical examples of this situation are:
To record all the Keys on a piece of paper. This turns the Key update into a poorly convenient task. This requires that this piece of paper is always available, and this is by far unsafe, as Keys are obviously not ciphered when they are hand written on a piece of paper.
To record all the Keys within a text file recorded on the computer from where the DataSet are accessed. Key updates are becoming less cumbersome as they consist in editing the file, and the availability of the Keys is ensured. Nevertheless this creates a security breach as an individual getting access to the computer where the file is recorded would automatically get access to all the Keys this file records.
To record all the Keys within a DataSet, the access of which is controlled by a Key. This solves to some extent the risk issue described above, but creates a “chicken and egg” situation because the access to the Keys requires a Key.
Furthermore, assuming that the user accepts to afford the above limitations and deficiencies, once a Key has been accessed, it must then be properly specified by the user to the target DataSet. This is a task prone to error as the elements constituting the Key must be specified in the right fields (do not swap the UserId and the Accountld for instance), and must be entered without spelling error (everybody has already once given a password with the Caps Lock key on . . . ). If the maximum number of retries for specifying the Key is reached, then the access can simply be lost, potentially putting the user in a tricky situation if the access to the DataSet is required for instance for critical business needs.
Put in other words, the problem is to manage a set of keys that can open doors with the following concerns:
Which is the right key for opening this door?
How to use this key for opening the door?
Where did I put the key?
Is the key strongly secured?